Known systems and methods for playing audiovisual content protected by intellectual property rights, such as movies or music, employ Digital Rights Management (DRM) technologies in which users pay to view the audiovisual content which they wish to view without also receiving advertising content.
Content producers and distributors who use this pay for content principle have been damaged by the creation of the Peer-to-Peer (“P2P”) networks which allow users to exchange files free of charge. There currently are several P2P networks, such as eMule, Ares Galaxy, and Bittorrent, which are widespread. The P2P transmissions are systems that take advantage of the upload bandwidth which every user has in order to allow users to share files. As a result of this upload bandwidth, every user who receives data from a file may send the data to other users. In this way, a network of users is created who may exchange among themselves the data that comprise the file, instead of each user downloading the file in its entirety from a provider site.
The owners of the intellectual property rights of the files that are distributed on P2P networks have taken numerous legal actions in different countries with the intent of trying to close down the P2P networks. Nevertheless, in many countries, the current legal situation of the P2P networks is not very clear and varies from country to country. Moreover, “pure” P2P networks have appeared in which there are no servers that may be closed down. These new networks use new technologies, such as Distributed Hash Tables (DHT) that allow the networks to operate without any server. Thus, there is no single central point for closing down the operation of the network. To close down a pure P2P network, a substantial portion of its nodes must be frozen, which makes it difficult to effectively close down these networks.
Despite increasing popularity of P2P networks and increasing complexity of DRM technologies, there has not been a significant effect on conventional television that applies advertising systems.
Another known system and method for playing videos uses streaming technology, which allows a user to begin to view the content while downloading it, without needing to wait for the file to be completely downloaded. These known systems may use a streaming protocol, e.g., the Real Time Streaming Protocol (“RTSP”), which is described in the RFC 2326 specifications published by the IETF (Request for Comments 2326, April 1998; currently available at the Internet address http://www.ietf.org/rfc/rfc2326.txt), the entirety of which is herein incorporated by reference. The operation of the RTSP protocol may be closely related to two other IETF (Internet Engineering Task Force) protocols, the SDP and RTP protocols.
The Session Description Protocol (SDP) is described in the RFC 4566 specifications published online by the IETF. (M. Handley et al., Request For Comments 4566, Network Working Group, July 2006, currently available at the Internet address http://www.ietf.org/rfc/rfc4566.txt), the entirety of which is herein incorporated by reference. The Real-Time Transport Protocol (RTP) is described in the RFC 3550 specifications published online by the IETF. (H. Schultzrinne et al., Request For Comments 3550, Network Working Group, July 2003, currently available at the Internet address http://www.ietf.org/rfc/rfc3550.txt), the entirety of which is herein incorporated by reference.
A newer draft of the RTSP protocol, designated as RTSP 2.0, is described in the document published online by the IETF “Real Time Streaming Protocol 2.0 (RTSP) draft-ietf-mmusic-rfc2326bis-16.txt”, H. Schulzrinne et al., MMUSIC Working Group, Nov. 19, 2007, currently available at the Internet address http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-16.txt), the entirety of which is herein incorporated by reference.
Another protocol related to the RTSP is the HTTP protocol (Hypertext Transfer Protocol) described in the RFC 2616 specifications published online by the IETF (R. Fielding et al., Request For Comments 2616, Network Working Group, June 1999, currently available at the Internet address http://www.w3.org/Protocols/rfc2616/rfc2616.html), the entirety of which is herein incorporated by reference.
The RTSP is a client-server protocol based on text messages designed to facilitate communication between a client and a streaming server, such that the client controls the streaming transmission from the server using the RTSP protocol as though it were a remote control of the server. The client may be any equipment configured to play a multimedia stream, such as a computer, a PDA, a mobile phone and in general any equipment that incorporates an audio or video player.
RTSP allows one or more flows of data, e.g., “streams,” to be established from the streaming server to the multimedia player. The RTSP protocol is the protocol that the multimedia player uses to communicate to the streaming server the content it wishes to receive by RTSP messages. The streaming server also sends RTSP messages to the multimedia player with information about the selected content and the way in which it is going to transmit it to the multimedia player.
The RTSP protocol uses the term “presentation” to refer to a set of streams that are presented together to the customer and that are defined in a presentation file called “Presentation Description” or “Presentation Description File.” Other protocols use different names to refer to a presentation. For example, the SDP protocol uses the term “session” to refer to a presentation.
The presentation file contains information about each stream that includes, for example, information on whether it is an audio or video stream, the type of coding used, Internet addresses needed to access each stream, or the like.
The presentation file may use various formats to describe this information. The SDP protocol is usually the most used, although it is not necessary to use the SDP protocol, and the RTSP protocol may describe the information using protocols other than the SDP. A file of a presentation is normally identified by a URI (“Uniform Resource Identifier”). For example, the next URI could be used to identify the file of a presentation:
rtsp://media.example.com:554/twister/audiotrack
The client may access the file of a presentation using the RTSP protocol or other protocols, such as the HTTP (Hypertext Transfer Protocol) protocol. The client may also receive the file that describes the presentation by electronic mail or by any other means.
RTSP uses the term “container file” to refer to a multimedia file that contains the data of one or more streams and which normally form a presentation when they are played together. For example, a container file may contain three streams: a first video stream of a movie, a second stream for the audio of the movie in English and a third stream with the audio in Spanish.
RTSP uses the term “RTSP session” to define an abstraction (for example a software module being run on the streaming server) that uses the streaming server to control each presentation it sends to each user. Each RTSP session is created, maintained and eliminated by the server. Normally a client requests to create a session by sending the SETUP command from the RTSP protocol to the server and receives an RTSP response from the server, called RESPONSE message with an identifier of the session created.
The RTSP sessions maintain information on the status of each presentation requested by each user. This is an important difference with respect to the HTTP protocol, which is a protocol that does not maintain the status of the client's requests.
Another important difference is that in the RTSP protocol, the server may send RTSP messages with commands to the client as well as receive them. The following table 1 taken from the RFC 2326 indicates the different commands, messages or methods in RTSP terminology, which may be sent between the client and the server. The RTSP server may send packets of data from each stream to the client using the RTP protocol, but RTSP does not depend on the RTP protocol and could use other carrier protocols.
TABLE 1methoddirectionobjectrequirementDESCRIBEC->SP, SrecommendedANNOUNCEC->S, S->CP, SoptionalGET_PARAMETERC->S, S->CP, SoptionalOPTIONSC->S, S->CP, Srequired(S->C: optional)PAUSEC->SP, SrecommendedPLAYC->SP, SrequiredRECORDC->SP, SoptionalREDIRECTS->CP, SoptionalSETUPC->SSrequiredSET_PARAMETERC->S, S->CP, SoptionalTEARDOWNC->SP, Srequired
In these known systems which use streaming protocols, a distributor may transmit a digital file to a user, and the user may view the digital file. The digital file may comprise a first portion which comprises advertising content, and a second portion which contains content which the user requested to view. The advertising content is presented to the user before the user requested content is presented to the user. Nevertheless, the streaming protocols allow the user to non-sequentially view the content of the digital file, such that the user is able to skip the advertisement, or fast forward through the advertising content, to reach the user requested content. Consequently, these known systems may not be effective with respect to achieving the goal of having the user view the advertising content.